Systems like mobile telephone systems may comprise a variety of databases of different types, which databases comprise data and may be queried by different query generating applications, such as by core applications in a core network or by third party applications. The database systems may then be divided into different levels or tiers, where there may be a data level, an application level and above this an enterprise level.
This type of division is necessary when there are many applications and many databases. A system having this type of structure is often denoted a federated database system.
Almost all kinds of application generate data. Most applications, log usage data of their clients for analytics. This makes the so called “Big Data” problem complex. Data to be stored and retrieved on a transactional basis is huge. In real time applications, like Home Location Register (HLR)/session description protocol (SDP) applications, the data handled is huge and should be retrieved from the database almost seamlessly. For such scenarios, a federated database setup consisting of a common data grid layer (for e.g., data nucleus) that distributes data over a wide variety of databases like HBase, Postgres, GraphDB etc., would be ideal. Highly relational data would be stored in structured query langue (SQL) based databases like Postgres. Graph based data would be stored in databases like Giraph.
The data grid takes care of the data transfer from/to applications and the databases. It distributes data in such a way that the latency to retrieve data is maintained. In such a case, the data grid is the most vital component that is responsible for the entire data. Failure of the data grid, especially in Telecom world cannot be tolerated as users will not be able to make calls. However, a central data grid instance can only handle limited traffic at any given instant. Distributing the data grid across multiple servers and handling the distribution of traffic across all instances of the data grid using a co-ordination service would be the ideal solution for this scenario.
The data grid layer in the existing federated database environments is furthermore centralised. Hence, if there is a failure of the data grid, there will be a blocking of the access to various data sources handled by the data grid. Failure is therefore not handled effectively in the existing federated database setups.
There is thus a need for improvement in the field of federated database systems, where one field of improvement is the handling of failures in data grid in order to obtain fault tolerance.